Current effort for the 3GPP LTE program is to bring new technology, new architecture and new methods in the new LTE settings and configurations in order to provide improved spectral efficiency, reduced latency, better utilizing the radio resource to bring faster user experiences and richer applications and services with less cost.
As part of these efforts, the 3GPP plans to introduce the concept of a HNB in LTE and possibly also wideband code division multiple access (WCDMA), GERAN and other cellular standards. The HNB is understood to be similar to the wireless local area network (WLAN) access point (AP) and can be designed in a manner that allows access to cellular services to users over extremely small service areas (e.g., homes or small offices). This can be particularly useful in areas where cellular networks have not been deployed and/or legacy RAT coverage exists and in areas where cellular coverage may be faint or non-existent for radio related reasons, (e.g., an underground metro or a shopping mall). The subscriber (e.g., an individual or an organization) can deploy a HNB over an area where such service is desired.
By introducing the concept of HNBs, the intent is to make HNBs ubiquitous and widely available. However, this means that several deployment scenarios should be considered. In particular the scenarios in which macro-cell coverage is unavailable either because of radio-related reasons (e.g., an underground tunnel) or because only legacy RAT coverage is available must be considered. Several issues need to be addressed for HNB implementations, some of which are set forth below.
Implementation of mobility between LTE Macro-cell and LTE HNB or between legacy 3GPP macro-cell like WCDMA and legacy 3GPP HNB (e.g., CMDA) and vice-versa when macro-cell coverage is available is an issue that should be addressed. Another issue is the implementation of mobility between HNBs. A third issue is that of implementation of mobility between LTE HNBs and legacy 3GPP RAT (e.g., WCDMA and GERAN) when LTE macro-cell coverage is unavailable. Implementation of mobility between legacy HNBs (e.g., Release 8 WCDMA) and LTE HNBs, between LTE HNBs and non-3GPP RAT (e.g., WLAN), and between legacy 3GPP HNB (e.g., WCDMA) and legacy 3GPP RATs are also valid issues.
Further, it may be possible to have hot-spot like deployments of HNB where operators (cellular or other business) choose to provide LTE coverage via HNBs in high-density areas (e.g., shopping malls, convention centers, etc.). It may be possible to implement differentiated charging policies that open new revenue streams for these operators which in turn may affect the decision of which coverage (macro-cell, HNB etc.) the wireless transmit/receive unit (WTRU)/network chooses to use. Therefore, the policies and implementation of differentiated charging mechanisms and their indication to HNBs are also open issues.
It is also implicit that the solutions to the problems mentioned above shall be consistent with the agreed requirements on mobility between LTE and other 3GPP access (e.g., GERAN, 3G), and LTE and non-3GPP access (e.g., WLAN).
Several high-level requirements exist for LTE-GERAN/universal terrestrial radio access network (UTRAN) inter-working. First, evolved UTRAN (E-UTRAN) terminals also supporting UTRAN and/or GERAN operation should be able to support measurement of, and handover from and to, both 3GPP universal terrestrial radio access (UTRA) and 3GPP GERAN systems correspondingly with acceptable impact on terminal complexity and network performance. Second, E-UTRAN is required to efficiently support inter-RAT measurements with acceptable impact on terminal complexity and network performance, e.g., by providing WTRUs with measurement opportunities through downlink and uplink scheduling. Third, the interruption time during a handover of real-time services between E-UTRAN and UTRAN is less than 300 ms. Fourth, the interruption time during a handover of non real-time services between E-UTRAN and UTRAN should be less than 500 ms. Fifth, the interruption time during a handover of real-time services between E-UTRAN and GERAN is less than 300 ms. Sixth, the interruption time during a handover of non real-time services between E-UTRAN and GERAN should be less than 500 ms. Another requirement is that non-active terminals (such as one being in Release 6 idle mode or CELL_PCH) which support UTRAN and/or GERAN in addition to E-UTRAN shall not need to monitor paging messages only from one of GERAN, UTRA or E-UTRA. The interruption time during a handover between an E-UTRA broadcast stream and a UTRAN or GERAN unicast stream providing the same service (e.g., same TV channel) is less than a value for further study (FFS). The FSS value is to be agreed upon following SA (Service and System Aspects) guidance. Finally, the interruption time during a handover between an E-UTRA broadcast stream and a UTRAN broadcast stream providing the same service (e.g., same TV channel) is less than FFS.
The above requirements are for the cases where the GERAN and/or UTRAN networks provide support for E-UTRAN handover.
Several high-level requirements also exist for LTE—non-3GPP access inter-working. First, the evolved 3GPP Mobility Management solution shall be able to accommodate terminals with different mobility requirements (e.g., fixed, nomadic and mobile terminals). Second, the evolved 3GPP mobility management should allow optimized routing for user-to-user traffic (including communication towards Internet and public switched telephone network (PSTN) users, e.g., via local break-out) and in all roaming scenarios (e.g., when both users are in a visited network). Third, the evolved 3GPP System shall support IPv4 and IPv6 connectivity. Inter-working between IPv4 and IPv6 terminals, servers and access systems shall be possible. Mobility between access systems supporting different IP versions should be supported. Finally, transport overhead needs optimization, especially for the last mile and radio interfaces.